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1. Introduction 


The future Air Traffic Management (ATM) concept shall be based on network centric 
operations, consequently on information sharing. In order to support such a vision not only a 
versatile and capable ground based communication network is necessary but also a network 
which includes the air to ground sub-networks which shall have sufficient capacity and 
capability. One such air to ground sub-network shall be established for the airport surface 
intended to be used by departing and arriving aircraft as well as by surface vehicles. This 
communication system is currently (2011) emerging and shall be called Aeronautical Mobile 
Airport Communications System (AeroMACS). AeroMACS shall be based on the IEEE 802.16- 
2009 standard (IEEE, 2009) and especially on the WiMAX Forum™ Mobile System Profile 
Specification rel1.0 v0.9 (WiMAX Forum, 2010). A draft profile has been developed and is 
being evaluated currently, e.g. in the EU research project SANDRA (SANDRA). 

The IEEE 802.16-2009 standard (IEEE, 2009) specifies the air interface of combined fixed and 
mobile point to multipoint broadband wireless access systems with the possibility to 
support different services. The standard specifies the Medium Access Control (MAC) and 
the Physical (PHY) layer, where the MAC is capable to support multiple PHY specifications 
applicable to a specific operational environment. Figure 1 depicts the protocol reference 
model of the IEEE 802.16 standard. The Service Specific Convergence Sub-layer (CS) accepts 
higher layer data protocol units (PDUs) via the CS service access point (SAP). Thereby, the 
CS classifies each higher layer PDU according to available policies and maps each higher 
layer PDU to a so called service flow identifier. The IEEE 802.16 standard provides multiple 
CS specifications in order to provide interfaces for a variety of higher layer protocols. The 
MAC Common Part Sub-layer (CPS) provides the core functionality for data exchange via 
the wireless medium. A separate security sub-layer is also available. Generally, the IEEE 
802.16-2009 standard provides a large amount of options. Thereby, different options may fit 
better for certain use cases than others. Due to the large amount of options it is merely 
impossible to be interoperable among different vendors based on the sole standard. 
Additional documentation and specification is necessary. This task has been conducted by 
the WiMAX Forum™. This group specifies so called "WiMAX profiles" where a selected set 
of options from the IEEE 802.16 standard is qualified for such a profile. 

The WiMAX Forum™ has been established in June 2001 and is an industry led nonprofit 
organization. The purpose of the WiMAX forum™ is to certify compatibility and 
interoperability of broadband wireless products based on the IEEE 802.16 standard. In such a 
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way rapid introduction of technology and market competition shall be enforced. The WiMAX 
Forum™ has many members comprising the majority of operators and equipment vendors. 
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Fig. 1. The IEFE 802.16 protocol reference model. 


The WiMAX Forum is organized into several working groups, one of them is the Technical 
Working Group (TWG), which develops technical product specifications and certification 
test suites for the air interface based on the OFDMA PHY. Such specifications are 
complementary to the IEEE 802.16 standards in order to achieve interoperability and 
certification of Mobile Stations and Base Stations conforming to the 802.16 standards. The 
TWG has produced a “Mobile System Profile Specification” which determines mandatory 
and optional functions. 

Sub-chapter 2 gives an overview of selected AeroMACS profile items with some 
explanations. Sub-chapter 3 discusses the possibilities to run IPv6 over AeroMACS. Sub- 
chapter 4 summarizes the outcome of the data traffic load analysis conducted during the 
course of the SANDRA project. Sub-chapter 5 shows selected results of the medium access 
performance analysis. At the end concluding remarks finalize this chapter. 


2. AeroMACS profile overview 


The WiMAX Forum™ Mobile System Profile Specification (WiMAX, 2010) represents a 
subset of the IEEE 802.16 standard (IEEE, 2009). Currently (2011) a draft profile for 
AeroMACS is being specified through standardisation bodies such as EUROCAE and 
RTCA. This draft profile is further evaluated by members of the SESAR Joint Undertaking 
and by members of the SANDRA project (GANDRA, 2011). The tentative AeroMACS draft 
profile is further a subset of the WiMAX Forum™ Mobile System Profile Specification. 
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Within this sub-chapter an overview of the core functionalities related to data exchange are 
given. 


2.1 Overview physical layer 

The Physical Layer (PHY) of the AeroMACS system shall be based on the OFDMA Physical 
Layer specification of the IEEE 802.16 standard with a channel bandwidth of 5 MHz. 
Thereby, the frame length shall be 5 ms. As the PHY will be based on the "Common part 
TDD profile" (WiMAX 2009), the Downlink and Uplink portions can vary dependent on the 
system settings (cf. Figure 2). 

The IEEE 802.16-2009 supports both Time Division Duplexing (TDD) and Frequency 
Division Duplexing (FDD) modes. However, AeroMACS shall be based on the TDD mode 
of operation. Reasons therefore are the dynamic allocation of Downlink (i.e. from Base 
Station to Mobile Station) and Uplink (i.e. from Mobile Station to Base Station) resources in 
order to efficiently support asymmetric Downlink (DL)/Uplink (UL) traffic, only a single 
channel is required which alleviates spectrum issues, and the TDD option is less complex. 


5 ms frame duration 
9 


DL subframe UL subframe 


S~ adaptive a= 


bs 


Fig. 2. AeroMACS frame with an adaptive DL/UL subframe width. 


The DL subframe and the UL subframe consist of a number of OFDM symbols where a 
reasonable setting could be 29 OFDM symbols for the DL and 18 OFDM symbols for the UL. 
However, the individual setting is dependent on the service provider. Valid values can be 
taken from the WiMAX Forum™ Mobile System Profile Specification TDD Specific Part 
(WiMAX, 2009). 

The standard supports multiple schemes for dividing the time and frequency resources 
among users, this may also be called sub-channelization. AeroMACS shall be based on the 
pseudo-random permutation for frequency diversity (i.e. PUSC). The available spectrum has 
to be utilized by the resource scheduler through an integer number of DL and UL slots, 
respectively. A slot is a logical n x m rectangle where n is the number of sub-carriers and m is 
the number of contiguous OFDM symbols. All slots, no matter which sub-channelization 
scheme is being used, contain 48 data symbols. Thereby, a DL slot consists of 2 OFDM 
symbols and 28 subcarriers. As the total usable amount of subcarriers is 420 for the DL, this 
results in 210 usable DL slots per 5 ms frame in the downlink direction (considering 28 
OFDM symbols plus 1 OFDM symbol used for the DL Prefix). In contrast a UL slot consists 
of 3 OFDM symbols and 24 subcarriers. For the uplink direction the total usable amount of 
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subcarriers is 408, consequently there are 102 usable UL slots per 5 ms frame in the uplink 
direction (assuming 18 OFDM symbols). 

Dependent on the coding and modulation scheme different throughput can be achieved. 
The modulation schemes are QPSK and 16 QAM for both directions as well as 64 QAM for 
the DL direction. 64 QAM is also being discussed as an option for the UL direction. 
Dependent on the robustness of the coding scheme different theoretical throughput values 
can be achieved. 


Table 1. Data size per DL/UL slot with various modulation and coding schemes. 


DL UL 

(64 QAM) 

CC1/2 | 48bits | 96bits | 144bits | 48bits | 96bits | (144 bits) 

CC2/3 | G4bits | 128bits | 192bits | 64bits | 128bits | (192 bits) 
CC3/4_ | 72bits | 144bits | 216 bits : : : 

CC5/6 | 80bits | 160bits | 240bits | 80bits | 160bits | (240 bits) 


DL (28 OFDM symbols) UL (18 OFDM symbols) 
QPSK 16 QAM 64 QAM QPSK 16 QAM | (64 QAM) 
CC1/2 | 2,016 Mbit | 3,859 Mbit | 6,048 Mbit | 0,979 Mbit | 1,958 Mbit | (2,9 Mbit) 
CC2/3 | 2,572 Mbit | 5,376 Mbit | 8,064 Mbit | 1,305 Mbit | 2,611 Mbit | (3,9 Mbit) 
CC3/4 | 3,024 Mbit | 6,048 Mbit | 9,072 Mbit - - - 
CC5/6 | 3,360 Mbit | 6,720 Mbit | 10,08 Mbit | 1,632 Mbit | 3,264 Mbit | (4,9 Mbit) 


Table 2. Raw data rate in megabits per second considering a setting of 28 usable OFDM DL 
symbols and 18 usable OFDM UL symbols. 


A broad range of combinations exists, however, most likely is a combination with robust 
coding (i.e. convolution code (CC) with rate 1/2) with modulation of QPSK or 16 QAM for 
the UL and 16 QAM or 64 QAM for the DL. 

Each 5 ms AeroMACS frame starts with a DL Prefix which occupies one entire OFDM 
symbol. The Frame Control Header (FCH) follows immediately the DL Prefix and contains 
information about the following DL Map. The DL Map and the UL Map are important 
management elements which tell the Mobile Stations (MSs) how the upcoming frame is to 
be used to exchange either data or management information. The mentioned elements of DL 
Prefix, FCH, DL Map, and UL Map appear in each DL subframe. The UL direction needs to 
schedule ranging opportunities for Mobile Stations in order to keep synchronized with the 
Base Station and in order to request bandwidth if a MS needs to do so. The remaining 
bandwidth may be used to transmit user data. 


2.2 Overview medium access control 

The IEEE 802.16 standard specifies a point to point and connection oriented link, i.e. each 
Service Data Unit (SDU) received from an interfacing higher layer is mapped to a unique 
and unidirectional service flow with specific quality of service (QoS) parameters. Thereby, 
the interfacing higher layer can be one of several different types. 

The MAC common part sub-layer operates in a point to multipoint environment. The Base 
Station (BS) is the only user of the Downlink (DL) resources, whereas the Mobile Stations 
have to share the Uplink (UL) resources. All MSs are able to receive DL transmissions. Based 
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on the Connection Identifier (CID) carried within the generic MAC header of each MAC 
PDU a MS is able to determine whether a MAC PDU is destined to it or not. 

A central concept of the IEEE 802.16 standard is the usage of transport connections which 
allows the utilization of QoS at MAC level. Each service flow has specific QoS parameters 
initialized at connection setup. Thereby, different data delivery strategies can be utilized 
(e.g. best effort, polling, etc.). 

At system initialization two pairs of management connections, namely the basic connection 
and the primary management connection, have to be established between the MS and the 
BS. A third management connection, the secondary management connection, may be 
established, too. However, such a connection is only mandatory for managed "subscriber 
stations". In certain circumstances especially if remote airport equipment is being used such 
a secondary management connection would probably make sense. However, the basic 
management connection shall be used to transmit short and time urgent MAC management 
messages while the primary management connection shall be used to exchange longer and 
delay tolerant MAC management messages. 


2.3 Convergence sub-layer options 

The convergence sub-layer (CS) in the case of the IEEE 802.16 standard specifies the 
interface towards higher layer protocols. The standard provides a variety of convergence 
sub-layer options in order to provide the possibility to interface with a versatile set of higher 
layer protocols. The principle functions of the convergence sub-layer are accepting and 
interpreting the higher layer protocol header and consequently the mapping of this 
information to a specific service flow. Additionally, header compression techniques or any 
other appropriate processing may be conducted by the convergence sub-layer protocol. 

The AeroMACS draft profile foresees only the IP CS (support of IPv6), however, optionally 
also the Ethernet CS is supported. In principle the issue of the convergence sub-layer seems 
straight forward - either AeroMACS supports higher layer protocol A or higher layer 
protocol B. However, recalling the principle design issues of layered communication 
protocol architectures there may be issues as discussed below. 

Figure 3 shows a generic view of a network reference model containing layers, interfaces, 
and protocols. Thereby, a layer of a network can be seen as an abstraction of a service or 
services to be provided to its higher layer. In such a way the implementation details are 
hidden from the service user, that is the higher layer. The higher layer accesses these 
services through a well defined interface (also known as service access point). The 
specification of clean interfaces provides the advantage to exchange completely different 
implementations of layers, assuming that the new implementation provides the same set of 
services as the old implementation did. Virtually, two communicating hosts are exchanging 
information on layer n using a layer n protocol. However, real communication takes place 
only via the physical transmission medium. Generally, a protocol specifies the rules and 
conventions to be used in a communication. 

A list of protocols used by a certain system, one protocol per layer, is called a protocol stack. 
Services and protocols are distinct concepts, although they are frequently confused. A 
service is a set of primitives (operations) that a layer provides to the layer above it. The 
service defines what operations the layer is prepared to perform on behalf of its users, but it 
says nothing at all about how these operations are implemented. A service relates to an 
interface between two layers, with the lower layer being the service provider and the upper 
layer being the service user. 
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Physical Transmission Medium 


Fig. 3. A generic protocol stack. 


A protocol, in contrast, is a set of rules governing the format and meaning of the frames, 
packets, or messages that are exchanged by the peer entities within a layer. Entities use 
protocols in order to implement their service definition. They are free to change their 
protocols at will, provided they do not change the service visible to their users. In this way, 
the service and the protocol are completely decoupled. 

Considering the two options of the packet based convergence sub-layer, namely IP CS and 
Ethernet CS. The offered service differs from the IP point of view and may cause problems 
when considering IP over AeroMACS (c.f. Chapter 3). 


2.4 MAC PDU formats 

The IEEE 802.16 standard offers various options for fragmenting and reassembling MAC 
Service Data Units. Thereby, a MAC SDU may be of variable or fixed length. In the case of 
AeroMACS a variable length of MAC SDUs shall be allowed. Generally, a MAC Protocol 
Data Unit shall be of the form as depicted in Figure 4. Each MAC PDU starts with a fixed 
length header of 6 bytes (the generic MAC header). A MAC PDU typically contains payload 
and shall then be appended by a 4 bytes Cyclic Redundancy Checksum (CRC). The payload 
itself may further contain several sub-headers (SH). The fragmentation sub-header is used if 
an entire MAC SDU does not fit into a single MAC PDU. The packing sub-header is used if 
several MAC SDU are packed together into a single MAC PDU. Multiple MAC PDU may 
also be concatenated during a single burst. 

If the MAC PDU does not contain payload data MAC header needs no CRC as the MAC 
header itself contains a header checksum. The generic MAC header contains the connection 
identifier (CID) of the connection with which the PDU is associated. The MAC PDU does 
not contain any source or destination address in its header. The tentative AeroMACS draft 
profile uses the same MAC PDU format specification as the WiMAX Forum (WMF) Mobile 
System specification (WiMAX Forum, 2010). 
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2.5 Automatic Repeat Request (ARQ) 

Generally, Automatic Repeat Request (ARQ) protocols are used to synchronize data flows 
between sending and receiving entities. Thereby, the flow control procedure takes care that 
the data source is not overloading the data sink. Also erroneous data packets are indicated 
to the source (through negative acknowledgments). 


MAG SDU 


Header Payload 


MAC PDU 


MAC Header ; CRC 
Gbytes) Payload (optional) eee 


MAC PDU - FRAGMENTED 
< > 


MAC Header Fragment SH CRC 
(G bytes} (2 bytes} | Payload (4 bytes} 


MAG PDU - PACKED 
a > 


MAC Packing MAC Packing MAC CRC 


Header SH SDU SH SDU (4 bytes) 
(E bytes} (3 bytes) (3 bytes) 


CONCATENATION 
= > 
sie MAC CRC M MAC CRC 
Ea Payload (4 bytes} ae Payload soe 


Fig. 4. Overview of different MAC PDU options. 


The IEEE 802.16 standard offers four different types of ARQ, namely, go-back-n, selective- 
reject, and two combinations of go-back-n and selective-reject. Go-back-n may also be called 
as cumulative ARQ. An ARQ information element has at least a size of 4 bytes and at most 
of 12 bytes. The basic components of an ARQ information element are the connection 
identifier field and the block sequence number (BSN) field. The CID identifies the transport 
connection and the BSN is differently used dependent on the ARQ type. 

The ARQ protocol of the IEEE 802.16 standard is based on ARQ blocks, which all have a size 
of ARQ BLOCK SIZE in bytes. An exception may only be for the last ARQ block of an SDU 
which may be smaller. Each incoming SDU from a higher layer is logically divided into a 
number of ARQ blocks. Thereby, each ARQ block gets a BSN. Compare Figure 5 which is 
showing an example with ARQ BLOCK_SIZE set to 32 bytes and a sequence of three 
arriving SDU with a size of 90, 10, and 64 bytes. 


SDU 2 
(10 bytes} 


SDU 1 
(90 bytes) 


block 1 block 2 block 3 block 4 block 5 block 6 
(32 bytes) | | (32 bytes) || (26 bytes) (10 bytes} (32 bytes) || (32 bytes) 


Fig. 5. Example of different SDU with an ARQ block size of 32 bytes. 


(64 bytes} 


| SDU3 | 
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The single blocks may be packed into one or several MAC PDUs. Using the above example 
all 6 ARQ blocks could be packed together to a single MAC PDU, however, the ARQ blocks 
could also be packed into 3 separate MAC PDU where each MAC PDU carries 2 ARQ 
blocks. ARQ blocks from the same SDU with consecutive block sequence numbers can be 
grouped together into an SDU fragment. Each fragment (or single ARQ block) is preceded 
by a packing sub-header (PSH) which carries the BSN of the first ARQ block and the length 
of the fragment in bytes. This allows the receiver to decode the ARQ blocks again. If the 
fragment length is not a multiple of ARQ BLOCK_SIZE, it means the last block in the 
fragment is smaller. The complete MAC PDU for the example case above where all ARQ 
blocks are sent in a single MAC PDU could look like as depicted in Figure 6. 


block 4 
(10 bytes} 
PSH PSH PSH 

3 bytes 93 bytes 3 bytes 13 bytes 3 bytes 67 bytes 


MAC MAC PDU 
6 bytes length = 179 bytes (173 bytes payload +6 bytes header) + 4 bytes CRC 


block 1 block 2 block 3 
(32 bytes} (32 bytes} (26 bytes} 


block 5 
(32 bytes} 


block 6 
(32 bytes} 


CRC 
4 bytes 


Fig. 6. Example MAC PDU - MAC packing. 


Figure 6 continues the example from above where 3 MAC SDUs are packed into a single 
MAC PDU. Each MAC SDU (fragment) is prefixed by a PSH which has a length of 3 bytes. 
Additionally, the MAC PDU overhead accounts for 10 bytes - i.e. the generic MAC header 
with 6 bytes and the CRC with 4 bytes. This example of packing MAC SDU results in an 
overhead of 19 bytes for a payload of 164 bytes. 


2.5.1 ARQ acknowledgment types 

Acknowledgment type 0 (ie. selective ACK entry) contains up to 4 fixed length 
acknowledgment maps. The length of such a map is 16 bits where each bit indicates whether 
a corresponding ARQ block has been received successfully (i.e. bit is set) or not (i.e. bit is not 
set). When using the selective ACK entry option the BSN corresponds to the first bit of the 
following acknowledgement map. It is important to realize that such an acknowledgement 
type is only applicable if more than or equal to 16 ARQ blocks have been received without 
prior sent acknowledgment. 

Acknowledgment type 1 (i.e. cumulative ACK entry) uses the BSN to cumulatively 
acknowledge all ARQ blocks received. This acknowledgment type has a fixed size of 4 bytes. 
Acknowledgment type 2 (i.e. cumulative with selective ACK entry) is a combination of 
acknowledgment type 0 and type 1. In this case the BSN is interpreted as cumulative 
acknowledgment and the first bit of the following map is set - the remaining bits of the map 
can be used as in type 0. 

Acknowledgement type 3 (i.e. cumulative with block sequence ACK entry) is a combination 
of type 1 and a series of sequence ACK maps. The BSN acknowledges all correctly received 
ARQ blocks cumulatively. The sequence ACK map contains either two sequences with a 
length given in 6 bits or three sequences with a length given in 4 bits. Thereby, each 
sequence specifies a number of consecutive BSN entries, with the first sequence starting at 
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the cumulative BSN plus one (which is always a negative acknowledgment; otherwise the 
cumulative BSN would be increased). 

Figure 7 shows a hypothetical example of 32 contiguous ARQ blocks where some of them 
were received correctly and some of them were received erroneously. Erroneous blocks are 
marked with an X. The differences of the various acknowledgment types become obvious 
when applying each acknowledgment type separately to the same set of ARQ blocks. In this 
case type 0 (i.e. selective ACK entry) is capable to give feedback on every received ARQ 
block. The reason therefore is that the number of ARQ blocks fits exactly two 
acknowledgment maps of 16 bits. The type 1 acknowledgment (i.e. cumulative ACK entry) 
can only confirm the receipt of the first three correctly received ARQ blocks. The type 2 
acknowledgment (i.e. cumulative and selective ACK entry) is capable of acknowledging 
only the first 18 ARQ blocks. The reason therefore is that selective ACK map sizes are fixed 
to a length of 16 bits, the remaining 14 ARQ blocks cannot be acknowledged by this method 
until erroneously received ARQ blocks are being retransmitted and received correctly. The 
type 3 acknowledgment (i.e. cumulative with block sequence ACK entry) uses sequences to 
acknowledge sequences of correctly or erroneously received ARQ blocks. If the option is 
used with 2 block sequences per sequence map (3a) only 20 ARQ blocks can be 
acknowledged. Using the option with 3 block sequences per sequence map (3b) 
acknowledges 27 ARQ blocks in this case. This example does not work well for the block 
sequence map option as the sequences are very short. 


~ Type3b > 

<I Type 3a > 

<4 Type 2 > 

-li> 

< Type 0 m 
< 32 ARQ Blocks > 
1 xX|x|6 x/|X |X |X |13) x |15] x | x [18 x |22 x (26) |X| xX |X| x [32 


Type 0: Selective ACK (size & bytes) 
BSN: 1 MAP: 1110011100001010 MAP: 0111011101100001 


Type 1: Cumulative ACK (size 4 bytes) 


Type 2: Cumulative + Selective ACK (size 6 bytes) 
BSN: 3 MAP: 1001110009101001 


Type 3a: Cumulative + Sequence ACK (size 12 bytes) — 2 sequence maps 
BSN: 3 SEQ: 01 2 3 SEQ: 01 4 1 


SEQ: 01 1 1 SEQ: 01 2 3 


Type 3b: Cumulative + Sequence ACK (size 12 bytes) — 3 sequence maps 
BSN: 3 SEQ: 010 2 3 4 SEQ: 101 1 1 1 


SEQ: 010 2 3 1 SEQ: 101 3 1 2 


Fig. 7. Illustration of the capabilities of the different ARQ acknowledgment types. 
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This example illustrates the functionality of the different ARQ options which may be used 
by the AeroMACS profile. Each ARQ option has its advantages depending on the frequency 
acknowledgments are sent (e.g. after the receipt of each MAC PDU, or after a certain 
amount of time, etc.), the pattern of the occurred errors, or the computational complexity. 
The WiMAX Forum™ Mobile System Specification requires ARQ acknowledgment types 1, 
type 2, and type 3 to be implemented. ARQ acknowledgment type 0 is optional. The 
AeroMACS profile intends to support the same set of acknowledgment options. 

Each acknowledgment type has its advantages but is dependent on feedback intervals, error 
patterns, and computational complexity. The size of the ARQ block has an impact as well, if 
large ARQ blocks are used it is more unlikely to fill acknowledgment maps or 
acknowledgment sequence maps. The standard does not specify any strategy how and 
when ARQ acknowledgments shall be scheduled. 


2.6 Qualtiy of Service (QoS) 

Quality of Service in IEEE 802.16 is supported through the concept of unicast transport 
connections. These transport connections are called service flows, where each service flow 
utilizes a particular set of QoS parameters. The standard provides several QoS parameters to 
be adjusted; for instance maximum sustained traffic rate, maximum traffic burst, minimum 
reserved traffic rate, maximum latency, etc. - in principle latency, jitter, and throughput 
assurance. 

Service flows are either provisioned or dynamically added by the Base Station or optionally 
by the Mobile Station. How to provision service flows is out of the scope of the IEEE 802.16 
standard, consequently it is also not specified in the AeroMACS draft profile. Certain service 
flows may be added dynamically for instance after the network entry procedure. The 
standard provides options to create, change, and delete a service flow dynamically. Such a 
procedures can be either initiated by the Base Station or by the Mobile Station. The WiMAX 
mobile profile makes these options mandatory to be supported by the Base Station. The 
capability to dynamically create or change a service flow is optional for a Mobile Station, 
however, the deletion of a service flow is mandatory. The AeroMACS profile intends to 
support only the dynamic service flow creation, change, and deletion procedures to be 
initiated by the Base Station. 

How these service flows are initiated and / or triggered is not specified by the AeroMACS 
profile. QoS parameters of ATC traffic flows shall probably be regulated while QoS 
parameters of AOC traffic flows may be provider dependent. 


2.7 Scheduling & data delivery services 

There are different possibilities to provide bandwidth to a Mobile Station, realized through a 
scheduling service. Uplink request and grant scheduling is performed by the Base Station in 
order to provide each Mobile Station with bandwidth for uplink transmissions or 
opportunities to request bandwidth. By specifying a scheduling type and its associated QoS 
parameters, the Base Station scheduler can anticipate the throughput and latency needs for 
the uplink traffic and provide polls and/or grants at the appropriate times. The different 
scheduling services are: 

e Unsolicited Grant Service (UGS) 

e real-time Polling Service (rtPS) 

e non-real-time Polling Service (nrtPS) 
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e Best Effort (BE) 

The unsolicited grant service (UGS) is intended for real-time applications which generate 
fixed-rate data. Among others QoS parameters such as tolerated jitter, minimum reserved 
traffic rate, maximum latency, and the unsolicited grant interval are defined. This means 
that a service flow with a data delivery service of UGS gets periodically UL resources 
assigned without requesting them each time. 

The real-time Polling service (rtPS) is intended for real time applications with variable bit 
rates. Among others QoS parameters such as maximum latency, minimum reserved traffic 
rate, traffic priority, and the polling interval are defined. In this case the resource scheduler 
polls a Mobile Station regularly at fixed intervals. These polls may be used to request 
bandwidth. 


Fixed Fixed Fixed Fixed 
packet size packet size packet size packet size 
p 
<td et time 


Periodic Intervals 


Fig. 8. The Unsolicited Grant Service (UGS) usable for uplink transmissions. 
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Fig. 9. The real-time Polling service (rtPS) usable for uplink transmissions. 
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Fig. 10. The non-real-time Polling Service (nrtPS) usable for uplink transmissions. 
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The non-real-time Polling Service (nrtPS) is intended for applications which require 
guaranteed data rate but are insensitive to delays. QoS parameters such as minimum 
reserved traffic rate, maximum sustained traffic rate, and traffic priority are defined. In this 
case the unicast polls are issued at a variable interval length (dependent on the available 
resources). The polls may be used to request bandwidth. 

The Best Effort (BE) service is intended for applications with no rate or delay requirements. 
In this case bandwidth request ranging opportunities are provided to transmit bandwidth 
request ranging codes. If a bandwidth request range code is successfully received by a Base 
Station it polls the associated Mobile Station. 


CDMA Ranging Opportunities 


| | data 1 data l data 1 data l 
p 


a paea se — ——— pea > time 


Non deterministic time intervals 


Fig. 11. The Best Effort (BE) service usable for uplink transmissions. 


For the downlink direction similar QoS classes can be utilized. However, these are called 
slightly different but have comparable QoS parameters. The scheduler does not need to 
consider any polls or ranging opportunities for the downlink, though. The different QoS 
classes or data delivery services are: 

e Unsolicited Grant Service (UGS) 

e Real-Time Variable Rate (RT-VR) service 

e Non-Real-Time Variable Rate (NRT-VR) service 

Best Effort (BE) service 

What kind of QoS class a specific application or set of applications will require is dependent 
on the requirements. How the different data delivery services and scheduling strategies are 
implemented is not specified by the standard. Thus, they are vendor dependent. In any case 
the communication service provider has to assure that safety related communication is 
preferred over non safety related communication. It might be that a simple priority scheme 
with a best effort service is sufficient. 


2.8 Request-grant mechanisms 

A Mobile Station is required to support at least three different connections. That is, two 
management connections which are set up at network entry and one data bearer to transmit 
user data. 

Every connection with a QoS service other than UGS needs to adapt its resource 
requirements. This is done through bandwidth requests. This is a mechanism where a 
Mobile Station indicates to the Base Station that it requires uplink resources. Bandwidth 
requests are either sent as standalone Bandwidth Request (BR) headers or as a Piggy Back 
Request (i.e. included in the Grant Management Sub-header (GMSH)). 
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Bandwidth Requests may be either incremental or aggregated. When a BS receives an 
incremental BR, it shall add the quantity of bandwidth requested to its current perception of 
the bandwidth needs of the connection. When the BS receives an aggregate BR, it shall 
replace its perception of the bandwidth needs of the connection with the quantity of 
bandwidth requests. Piggybacked bandwidth requests are always incremental. 

The Base Station issues resource grants towards a Mobile Station based on the basic CID (i.e. 
basic management connection). This means that a Mobile Station is able to utilize the 
concept of bandwidth stealing where a certain amount of requested bandwidth for a specific 
QoS class may be utilized differently. However, the resource requests are based on the 
transport connection which requires bandwidth. If a Base Station polls a Mobile Station it 
typically assigns enough resources to issue a bandwidth request. 


3. IPv6 over AeroMACS 


The Network Working Group (NWG) of the WiMAX Forum™ has defined a network 
architecture for IEEE 802.16 sub-networks. Thereby, considering topics at layers above those 
defined by the 802 standards. The Internet Engineering Task Force (IETF) has worked out a 
Request For Comment (RFC) "Transmission of IPv6 via the IPv6 Convergence Sub-layer 
over IEEE 802.16 Networks" (RFC 5121, 2008) which provides a full conformant IPv6 
connectivity through an IP point to point link. This solution fits the general business use 
case where each subscriber resides in its own sub-network. However, the requirements of 
the sub-network in an aeronautical environment might be different than the one of an 
ordinary business use case. Running IPv6 over AeroMACS shall be fully compliant to the IP 
standard, thereby, IP multicast shall be supported preferably in an efficient manner. It might 
also be desirable to support multicast at link layer which is difficult with point to point 
links. The problem statement and possible different solutions are discussed in the following. 
First of all it is important to identify the relevant concepts of IPv6 addressing. In IPv6, nodes 
are attached to an access network via an interface, which is given at least one IPv6 address 
(i.e. the link local unicast address). Within this context a node can be understood as a device 
which implements IPv6. This means that an interface gets one or more IPv6 addresses 
assigned and not the node itself, which is a fundamental concept of IP. In other words a 
node may host several network interfaces which have different addresses. Thereby, the 
same node may be reachable through different IPv6 addresses. 

An IPv6 capable node must be able of configuring its IPv6 address autonomously. An IPv6 
address is created through a valid interface identifier and a valid subnet prefix. The subnet 
prefix may be a constant link local prefix (i.e. FE80::0), an advertised prefix received by 
Router Advertisements, or a prefix by a DHCPV6 server. The prefix is only valid on the link on 
which it is received - the prefix shall not be used on different links. Link local addresses 
allow communications between devices on a local link; such addresses cannot be used to 
communicate outside a network link. 

Native multicast capability can be described through the following general concepts of the 
IP addressing model - first through the concept of a link and secondly through the concept 
of a subnet. A link is a term used to refer to a topological area bounded by routers that decrement 
the IPv6 Hop Limit when forwarding a packet (c.f. RFC 4903, 2007). The term subnet is generally 
used to refer to a topological area that uses the same address prefix, where that prefix is not further 
subdivided except into individual addresses (c.f. RFC 4903, 2007). Thereby, it is important to 
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recognize that IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple 
subnets may be assigned to the same link (c.f. RFC 4291, 2006). Ideally, the Data Link layer 
addressing mechanisms can be directly used for the Internet Protocol addressing method. 
Some of the Internet layer protocols (e.g. Address Auto-configuration (RFC 4862, 2007), 
Neighbour Discovery (RFC 4861, 2007), Dynamic Host Configuration Protocol (RFC 315, 
2003), or more generally protocols used for service discovery or name resolution) require 
native multicast capability of the underlying link, that is data packets can be distributed to 
all interested nodes on the same link without a decrement of the IPv6 Hop Limit field. If 
such a native multicast capability is not given by a certain link technology, an IP link model 
has to be presented towards the Internet layer which fulfils this requirement. 

In principle, if a physical link characteristic is problematic at the Internet layer, mechanisms 
have to be defined that the link model appears properly at the Internet layer. The Internet 
Architecture Board (IAB) recommends using one of the two following models: The multi- 
access link model or the point to point link model. These models, if implemented properly, 
have no problems regarding the IP addressing model and the native multicast capability (c.f. 
RFC 4903, 2007). 


3.1 IP point-to-point link model 

Figure 12 considers a generic configuration of the IP point to point link model. Here exactly 
two nodes (i.e. Node A and Node B) are located on the same link. Native multicast is 
supported, that is, both nodes on the link are able to receive data packets which are sent to a 
link local multicast address. Also, both nodes can communicate with each other without any 
IPv6 Hop Limit decrement. Any Layer 2 device (e.g. bridges, switches, etc.) connected in the 
middle of the link is allowed. In terms of AeroMACS Node A would reflect the Mobile 
Station (MS) and Node B would be an Access Router, respectively. 
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Fig. 12. A generic configuration of a "Point-to-Point Link Model". 


3.1.1 Single prefix per mobile station 

Considering the IP point to point link model presented to the network layer one possibility 
is to provide a single prefix to each Mobile Station. The AeroMACS communication system 
may make use of the IP convergence sub-layer (CS) or the Ethernet convergence sub-layer. 
In principle both solutions would work for the point to point connection, however, from a 
standard's point of view the two components are distinguished as the Ethernet 
configuration would allow a bridging functionality which the IP configuration does not. 
Examining the case where data traffic is transmitted from the Mobile Station to the access 
router the following steps occur (cf. Figure 13): 
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1. An IPv6 packet is handed over to the convergence sub-layer. There the protocol fields 
of the higher layer data packet map to a Service Flow Identifier (SFID) that further maps 
to a Connection Identifier (CID). The connection identified through the CID is used to 
transmit the higher layer data packet to the Base Station (BS) - which is a layer two 
device as depicted in the Figure 12. 

2. The "Data Path Function" of the BS encapsulates the IPv6 packet into a Generic Routing 
Encapsulation (GRE) tunnel. A unique GRE tag maps to the SFID of the connection. 

3. The "Data Path Function" of the ASN Gateway receives the IPv6 packet and forwards it 
accordingly. 

The other direction works analog. The "Data Path Function" of the ASN GW and the BS use 
the unique GRE tag to map to the SFID and CID of a connection, respectively. In such a way 
a virtual tunnel from the Access Router to the Mobile Station and vice versa is created. The 
“Data Path Function” creates the tunnel on a per service flow granularity. From an IP point 
of view these GRE tunnels have to be presented to the IP layer as “virtual interfaces” as each 
interface is more or less a single link. In such a way distinct prefixes have to be advertised 
on each link making the link a pure point to point link at layer 2 and layer 3. The main 
drawback of that solution is that standard multicast capabilities of the AeroMACS sub- 
network are disabled by default. 
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Fig. 13. Protocol stacks of different entities, considering an IP point to point link model. 


3.1.2 Shared prefix for all mobile stations 

If a shared prefix is used for all "Virtual Interfaces" the IP link model is violated, as the same 
prefix is advertised on different links. If only a single IP prefix is used (and native multicast 
among all attached Mobile Stations is being supported) an additional function is required 
(some kind of backend process). If a shared prefix is being needed for an AeroMACS 
system, the AeroMACS link as such has to be presented as a single link to the IP process. 
Therefore, some kind of backend process (or a similar approach like MLD snooping) is 
required. Such a backend process is no standard solution and would require a separate 
specification and implementation - sucha solution is probably not desired. 


3.2 IP multi-access link model 

Figure 14 shows a generic configuration of a multi-access link model. One link is shared by 
one or more nodes (i.e. Node A, Node B, Node X, etc.). Thereby, the link may be attached to 
one or more routers. However, a router is not stringently necessary. Native multicast is 
supported, that is, all interested nodes on the link are able to receive data packets which are 
sent to a link local multicast address. Additionally, two nodes on the same link can 
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communicate with each other without any IPv6 Hop Limit decrement. Any Layer 2 device 
(e.g. bridges, switches, etc.) connected in the middle of the link is allowed. 

The IEEE 802.16 over Ethernet option would provide such functionality - realized through 
the Ethernet CS interface and an Ethernet bridge (realized as layer 2 device). The 
AeroMACS link is presented to the IPv6 capable router only as a single interface. Note that 
the presentation of the single interface to the IP process as such has to be handled by the 
"Data Path Function" similar to the "backend process" presented earlier. The "Data Path 
Function" will encapsulate the data packets into a GRE tunnel and map them accordingly to 
a SFID and CID, respectively. Such a solution would be only possible if the Ethernet CS 
option is being used as the IP CS solution does not offer any possibility to bridge the data 
traffic. 
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Fig. 14. A generic configuration of a "Multi-Access Link Model". 
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Alternatively the general encapsulation convergence sub-layer could be used to come up 
with a specific solution for the aviation case. However, this is no standard solution and 
would require additional development resources. A process which is not desired. 


3.3 IP multicast 

If one of the above mentioned IP models is implemented properly for the AeroMACS 
communication system IP multicast is always possible, as the system is fully IPv6 compliant. 
However, the advantage of IP multicast should be to transfer the data packet only as often 
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as necessary. Utilizing an IP point to point link model means that each multicast data packet 
transmitted to a group of multicast listeners belonging to the same cell and / or sector of a 
Base Station needs to be multiplied by the amount of listeners. Utilizing the Multi-Access 
link model means that the data packet is transmitted only once to the same group of 
multicast listeners belonging to the same cell/sector of a Base Station - this might increase 
the efficiency of an AeroMACS communication system. 

In standard business cases of the mobile communication industry this may have no large 
impact. However, the aeronautical business case may have a larger interest in multicast 
applications. Therefore, the advantages and drawbacks of the different solutions shall be 
analyzed in depth in the future. 


4. Future data traffic 


Different types of application may utilize the AeroMACS communication system, among 
these could be fixed users, mobile users, and aircraft. By the term fixed users airport LAN 
extension could be considered such as unique equipment (terminals, cameras, etc.). Also 
Aeronautical Navigation Service Provider (ANSP) managed equipment like area navigation 
(RNAV) systems could be interpreted as fixed user. Mobile users would be airport surface 
vehicles such as airport trucks (catering, maintenance, refueling trucks, etc.) or mobile 
terminals which support for instance voice over IP. Aircraft would utilize an AeroMACS 
system by applications such as Air Traffic Control (ATC), Aeronautical Operational 
Communications (AOC), or Aeronautical Administrative Communications (AAC) which 
may have a direct operational and safety impact. 
In order to assess the performance of an AeroMACS communication system properly an 
assumption on the data traffic load for airport surface communications was necessary. This 
sub-chapter summarizes the results of the data traffic load analysis for aircraft and mobile 
users conducted during the course of the SANDRA project (SANDRA). Services as 
anticipated by the COCRv2 report (COCR, 2007) and the AOC data link dimensioning 
report (AOC, 2010) were considered. In order to simulate a data traffic model the following 
inputs were necessary: 

e = An air traffic model: A simulation of the aircraft movement on the airport. That is, 
departing aircraft moving from ramp to runway, arriving aircraft moving from runway 
to ramp, and ground vehicles. 

e Supported applications: Data link applications envisaged for the airport domain and 
their trigger events. Note that most aeronautical data link applications are triggered by 
events related to the progress of the flight. The events are provided by the air traffic 
model. 

e Scenarios: These are the different use cases of the airport data link. This relates mostly 
to the amount of aircraft serviced, and the various sets of supported applications. 

The output of the data traffic model is the statistical description of the expected offered load 

at application layer (ISO/OSI layer 7). The offered load is the amount of data produced by 

the applications - this does not include any overhead of the transport layer, network layer, 

or data link layer. Details about the implemented model can be found in (Ehammer, 2011). 

The outcome of the evaluation showed that ATC applications contribute insignificantly to 

the offered load (in the order of a couple kbits/second), as these applications are mostly 

short. However, certain AOC applications may contribute significantly to the overall load, 
especially those related to software updates or post flight procedures. Results showed that 


www.intechopen.com 


280 Future Aeronautical Communications 


an average offered load of several megabits per second is possible. Thus justifying an 
introduction of a broadband wireless communication system at airports. 


5. Simulation results 


Within the SANDRA project MAC performance simulations have been conducted in 2011. 
Initial results are presented within this sub-chapter. In principle there are two different sets 
of WiMAX functions defined by the Mobile System Profile (as of IEEE 802.16-2009) - i.e. a set 
of functions to establish point to point connections over which data can be exchanged and a 
set of functions to support mobility. Within this sub-chapter a performance evaluation 
regarding data exchange functions is given. 

In order to perform the evaluation a tool chain as depicted below has been used. Thereby, 
the parameter set is defined through simulation scenarios. The simulation itself is built 
according to requirements defined by simulation scenarios. The statistic program uses the 
XML based output data produced by the simulation as input to generate HTML reports 
which shall contain all necessary statistics in order to assess the different functions of the 
AeroMACS MAC layer. A similar approach has been conducted in several projects using the 
method described in (Ehammer, 2008). 


Parameter Simulation XML based Statistic HTML 
Set output data Program Report 


Fig. 15. Simulation tool chain. 


The simulation effort concentrated solely on the MAC layer as depicted in Figure 16 below. 
The data transported through the connection (Mobile Station to Base Station) has been 
elaborated in a separate task (c.f. Chapter 3). However, the data traffic used for this 
evaluation is a synthetic data stream using a constant bit rate. The Physical Layer is modeled 
very simple through a uniformly distributed bit error rate (BER). 
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Fig. 16. Protocol stack of involved entities. 
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5.1 Evaluation 

A basic set of parameter settings is evaluated against 

e A varying bit error rate (the BER scenario). 

e A varying load (the LOAD scenario) 

e A varying amount of active users within the cell (the PIAC scenario). 

Thereby, parameters such as latency, throughput, or loss are measured. Detailed evaluations 
show overhead figures resulted from the protocol itself and overhead caused through re- 
transmissions due to bad channel conditions. The evaluation scenario of varying bit error 
rates assumes a constant load and a constant amount of active users. Similarly, the 
evaluation scenario of varying load assumes a constant bit error rate and a constant amount 
of active users. Finally, the evaluation scenario of varying active users assumes a constant 
bit error rate and a constant load. For each evaluation a scenario is simulated several times 
in order to gain appropriate confidence intervals. 


5.1.1 Reference scenario 

The reference simulation scenario demonstrates basic data exchange capabilities of the 
AeroMACS protocol. The basic set of options necessary are the fragmentation and re- 
assembly options, the ARQ implementation with all allowed acknowledgment types set, a 
dynamic service flow addition capability (initiated by the Base Station after network entry), 
and the basic resource request and resource grant options. 

The basic idea is to establish a data connection which has a QoS of "Best Effort". 
Additionally, this data connection shall support ARQ. Almost every time an aircraft has to 
transmit a data packet a resource request has to be issued - this is realized through the 
transmission of a CDMA ranging code via the ranging slot dedicated for periodic or 
bandwidth request ranging. If an aircraft has resources available it can also transmit a 
bandwidth request piggybacked via the "Grant Management Sub-header". Depending on 
the bit error rate, there will be loss. The sole bandwidth request header carries always 
aggregated bandwidth requests while the piggybacked bandwidth request carries 
incremented bandwidth requests. The maximum allowed PDU size is critical, especially if 
the bit error rate is high. It has to be coordinated with the ARQ block size as well. 
Obviously, larger ARQ block sizes than maximum fragment sizes do not make much sense. 
The evaluation is based on a generic traffic generation where higher layer data packets have 
a typical IPv6 MTU size (ie. 1500 bytes). The load per aircraft for uplink direction and 
downlink direction is assumed to be constant (evaluation in discrete steps from low load to 
high load). The amount of active participants (i.e. Mobile Stations or surface vehicles) per 
cell is assumed to be constant (evaluation in discrete steps from low to high). The bit error 
rate is assumed to be constant (evaluation in discrete steps, from good channel to bad 
channel conditions). 


5.1.2 Simulation parameter settings 

The simulation itself has a series of parameters to be considered the most important 
parameters for the BER evaluation scenario are briefly discussed. For the BER evaluation 
scenario 20 Mobile Stations are considered. Thereby, each MS shall generate on average a 
load of 60 kbps for the downlink direction and a load of 30 kbps for the uplink direction. 
The QoS parameters are set to Best Effort (BE). That means bandwidth request ranging 
opportunities have to be utilized if no resources are available when higher layer data 
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packets arrive. The maximum fragment size is set to 612 bytes. The ARQ settings are 128 
bytes ARQ block size, 500 ms ARQ retry timeout, 10 seconds ARQ block lifetime, and all 
allowed acknowledgment types are enabled. Furthermore, acknowledgments may be 
piggybacked, bandwidth resource requests may be issued via the GSMH header 
(piggybacked), the compressed map feature is enabled, and packing of different MAC SDU 
is allowed. The BER values vary from 107 to 10°. The modulation and coding scheme has 
been chosen to be QPSK and CC rate 1/2. Different coding and modulation schemes should 
produce similar results except with higher throughput rates. Figure 17 shows an AeroMACS 
frame how it has been utilized for the presented simulation results. The DL-Prefix is present 
in each DL sub-frame as well as the DL and UL map. Downlink and Uplink Channel 
Descriptors (DCD/UCD) are transmitted periodically. Ranging opportunities such as initial 
and handover ranging slots or bandwidth request and periodic ranging slots are offered 
periodically as well. Dependent on the amount of BR ranging codes issued a variable 
amount of CDMA allocations have to be made available for Mobile Stations in the UL 
direction. 
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Fig. 17. Typical AeroMACS frame structure for this evaluation scenario. 


5.1.3 Selected results 

The figure below illustrate the higher layer (HiL) goodput and the data link layer (DLL) 
goodput. Goodput can be interpreted as user throughput, i.e. the number of useful bits per 
unit of time successfully forwarded by the network from a certain source address to a 
certain destination, excluding protocol overhead, and excluding retransmitted data packets. 
The figures underneath show the Forward Link (FL) and Reverse Link (RL) goodput. FL and 
RL are aeronautical terms where FL is the equivalent of DL and RL of UL, respectively. 
Furthermore, the figures underneath also show the FL and RL average latency for higher 
layer data packets and data link layer data packets. Note that the latency of data link layer 
packets is negligible as the transfer of a single MAC PDU takes at most 2 ms. 

The FL results (i.e. Base Station to Mobile Station) show a controlled behavior until a BER of 
10-5. The higher layer data packets are still delivered at a BER of 5x105, however the 
DLLgoodput increases due to re-transmissions caused by ARQ timeouts. As a result the 
average latency increases from approximately 100 ms to 1000 ms. Further decreasing the the 
channel (i.e. BER equals 104) results in massive loss of higher layer data packets. packets. 
Higher layer packets are dropped as soon as the ARQ block lifetime of a MAC SDU (i.e. the 
higher layer data packet) expires. This is also reflected in the average FL latency which is 
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slightly underneath the ARQ block lifetime of 10 seconds (the graph accounts only for 
higher data layer packets which were delivered successfully). Decreasing the channel 
quality another time (i.e. BER equals 5x10-4) results in total loss of data as well as almost no 
throughput of DLL data. 

Considering the RL (i.e. Mobile Station to Base Station) a controlled behavior is only 
available until a BER of 105. After that a similar behavior than the one of the FL can be 
observed. Due to the nature of the scheduling strategy used for the RL (i.e. best effort), 
acquiring new resources may be more time demanding, therefore an ARQ block lifetime 
timeout is more likely with a similar error rate than in the FL. 
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Fig. 19. RL Goodput - scenario BER. 
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Fig. 20. FL avg. latency - scenario BER. 
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Fig. 21. RL avg. latency - scenario BER. 


The LOAD evaluation scenario utilizes exactly the same parameter set than the BER 
evaluation scenario, except the bit error rate and the data traffic load. The LOAD scenario 
simulates a rather good channel condition, i.e. BER equal to 10-6. The purpose of the LOAD 
scenario is to increase the load in steps starting from 9 kbps per Mobile Station RL data 
traffic and 18 kbps per Mobile Station FL data traffic. The intervals were set to 2 kbps for the 
RL and 4 kbps for the FL. Most load is generated by when 35 kbps for the RL and 70 kbps 
for the FL are set. 

On the FL the higher layer data packets get all through, so do the data link layer packets. 
The DLL overhead stays proportional for all simulation scenarios. The average FL latency 
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increases slightly with more load but is still insignificantly. The RL goodput figure shows an 
interesting behaviour. Namely the slightly larger DLL goodput with low load. The reason 
therefore is that with low load resource request are less likely to be piggybacked. Thus, 
every time a higher layer data packet arrives a separate bandwidth request has to be issued. 
The overhead is significantly for lower loads as periodic ranging opportunities are 
accounted for DLL goodput. This overhead stays similar with higher loads, however, 
relatively the overall overhead decreases. The RL average latency starts to increase when the 
RL load starts to reach the capacity limit. 
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Fig. 22. FL goodput - scenario LOAD. 
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Fig. 23. RL goodput - scenario LOAD. 
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Fig. 24. FL avg. latency - scenario LOAD. 
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Fig. 25. RL avg. latency - scenario LOAD. 


The PIAC (Peak Instantaneous Aircraft Count) evaluation scenario utilizes exactly the same 
parameter set than the LOAD evaluation scenario, except the amount of Mobile Stations and 
the data traffic load. The PIAC scenario simulates an average load of 20 kbps per Mobile 
Station FL data traffic and an average load of 10 kbps per Mobile Station RL data traffic. The 
amount of Mobile Stations is set to 10 and increased by intervals of 5 up to a maximum 
value of 80. 

The FL higher layer goodput is reasonable until an amount of 70 concurrent users (and data 
traffic service flows). After that the throughput decreases and average latency figures 
increase. The RL higher layer goodput is stable until an amount of 50 concurrent users. 
However, the data link layer goodput increases with each interval. The reason therefore is 
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that bandwidth request ranging opportunities are served with unicast polls. The more 
concurrent Mobile Stations reside in a single cell, the more overhead is caused through this 
procedure. The higher layer goodput decreases after more than 50 Mobile Stations are trying 
to transmit concurrently. The DLL goodput is not reaching its maximum as the RL data sub- 
frame gets seriously fragmented through the unicast polls issued by the Base Station. As a 
result the scheduler gets serious problems utilizing the full spectrum sufficiently. Recall, 
that ARQ blocks have a fixed size. The average RL latency reflects the ARQ block lifetime. 
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Fig. 27. RL goodput - scenario PIAC. 
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Fig. 29. RL avg. latency - scenario PIAC. 


6. Conclusion 


The demand to integrate the aircraft into the network centric concepts requires capable air 
ground data-links. AeroMACS shall provide this functionality at the airport surface. 
Infrastructure and equipage used for aeronautical procedures is evolving very slowly due to 
several reasons. Cost, interoperability, and safety issues are some among many reasons. Any 
new system integrated into the aeronautical environment will last for decades until it might 
eventually be replaced through a new system. Therefore, it is of importance to design new 
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systems carefully and with mature concepts in order to remain prepared for changing 
requirements in the future. 

Integrating the AeroMACS sub-network into an IPv6 based aeronautical telecommunication 
network (ATN) is generally a problem which needs to be resolved from the application's 
point of view and from the operator point of view. It is also important to keep flexibility in 
order to be capable to adapt to any future changes of requirements. Especially if products 
have such long life cycles as in the aeronautical world it is almost impossible to assess the 
proper requirements. 

Multicast applications may be very attractive to the future ATM concept, however, most of 
these applications are not realized yet (i.e. they exist only in theory). With a wrong sub-net 
configuration the introduction of application layer concepts based on multicast may be quite 
difficult and/or expensive. 

During the course of the SANDRA project a data traffic load analysis has been conducted 
which showed that applications with significant load requirements would justify the 
introduction of a broadband wireless communication system for airport surface 
communications. Furthermore, MAC performance simulations have shown performance 
figures to be expected by a future AeroMACS system. 

The current status of the AeroMACS profile is a draft. This means that further assessments 
on the maturity and performance of the technology shall clarify the suitability of AeroMACS 
for supporting the needs of future ATM concepts. Although currently prototypes are being 
implemented it is not believed that AeroMACS would be introduced before 2020. A realistic 
target for the deployment of an AeroMACS system is rather 2025 and beyond. 
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